PCISlots is a simple utility for displaying information on any cards installed in PCI slots on Power Macintosh computers.
It uses the NameRegistry to discover what slots have cards in them, and then displays information on these cards to a simple console window.
PCISlots is provided in 3 different forms - a native PowerPC application, a 68K application that calls native PowerPC routines, and a "fat" application that contains both the former parts.
If launched on a 68K Macintosh, an appropriate error message or Alert will be displayed. If launched on a Power Macintosh that does not support PCI slots, an appropriate error message or Alert will be displayed. If there are no cards installed in a machine that supports PCI, an appropriate error message will be displayed. If other error conditions are detected, appropriate error messages (or in some cases a debugger break) will be displayed.
Usage :
-----
Simply launch the desired version on the machine under test. The results should be self-explanatory. The name displayed within () for a particular slot is there purely for debugging purposes. The contents of the console window can be printed or saved to a MPW text file.
The information displayed by the utility can be extended/modified by use of a resource editor such as ResEdit, as follows :
1) Open up the application with ResEdit, then open up STR# resource ID = 10001. A list of NameRegistry property names is shown. You may add to, remove, or change any of these strings to correspond to valid NameRegistry property names (you can use the DisplayNameRegistry utility for this purpose).
2) Open up STR# resource ID = 10002. A list of formatting strings used to display NameRegistry property values is shown. There is a one-to-one correspondence between the strings in STR# resource ID = 10001 and those in 10002 - i.e. if you make a change in one STR# resource, you must make a corresponding change in the other STR# resource. The formatting strings accept standard C 'printf' formatting commands, except that you are currently limited to simple strings, bytes, words, and long words (i.e. don't try to format large multi-byte property values).
3) Save changes, and quit.
Bugs :
----
v1.0d2 :
If launching the PPC or FAT versions on a Power Macintosh that does not support PCI slots (and doesn't have the native NameRegistryLib installed), the Code Fragment Manager will display an Alert saying the NameRegistryLib is missing before the application finishes launching - for some reason my "weak" imports are not working correctly.
The MetroWerks CodeWarrior version doesn't have an easy way of moving the native PPC code stored in the data fork of the "shared library" file PCISlotsNameRegistry.PEF to the expected location in a resource of type 'XCOF' and ID = 10000 in the PCISlots.68K.cw application. However, having done so, the resulting application still crashes when trying to set up the native PPC code.
The error handling could be improved to give more specific and meaningful feedback to the user.
Version History :
--------------
v1.0d2 - 18 July 95 - Tidied up the source code, so it is little more useable by people outside of Apple. Added support for finding the slot # for given driver refNum - this routine is not used in this specific application, but it might be useful to someone else - see the source files for details. Provide separate and generic setup/teardown routines for PPC native code. Changed error handling for PCI on machines that don't have the slots but do have NameRegistry support in ROM/System software. Tidy-up source for PPCC v1.0.5, Universal Headers v2.0 final, PCI DDK v1.0GM (PCI Interfaces DDK v23c5. Monday, May 15, 1995), CodeWarrior 6.1.
v1.0d1 - 26 May 95 - First public release (with a real icon!). Source code is not available yet. Compiled with MPW 3.3.1 and PCI Interfaces/Libraries from the PCI DDK v22c2 (Wednesday, April 19, 1995). Uses SIOW.
Building from source :
-------------------
(a) To build the MPW (3.3.1 from ETO #17) version :
Set directory to the PCISlots folder, and don't disturb the folder hierarchy. On the MPW worksheet, enter the following command :
SCMBuild -fat
This script that can take various options. Type "SCMBuild -help" for more information.
(b) To build the Metrowerks CodeWarrior (CW6 Gold patched to 6.1) version :
Open up each of the 3 projects, and Make them. The NameRegistry.h and NameRegistryLib files are taken directly from the PCI DDK (and are only required for the CodeWarrior version).
To make a FAT binary, simply use ResEdit to copy the contents of the 68K application to a copy of the PPC application (you can probably safely replace existing resources) - yes, I could have created a project that made a FAT version automatically, but if I ever got the rest of the project to work correctly (see bugs above), then the 'XCOF' resource would have come along, and would be a waste of space etc.
The PPC version will work as is. To make the 68K version work, you need to move the native PPC code stored in the data fork of the "shared library" file PCISlotsNameRegistry.PEF to the expected location in a resource of type 'XCOF' and ID = 10000 in the PCISlots.68K.cw application. There are probably several ways of doing this; the following is one way that works using MPW and assumedly ToolServer - enter this on the Worksheet (all one line) :
The source code is not an example of programming brilliance. It could be made much more efficient. The code is designed to build as both completely native PPC code, or as a 68K shell application making mixed mode calls to the native PPC NameRegistryLib library. There are also other ways of calling the mixed mode code. However in order to keep the same source for both versions, I resorted to some tricks with C macros (defined in PCISlots.h) to do all the hard work - in native PPC code, the macros expand to simple calls to the native PPC NameRegistryLib shared library. In the 68K code case, the macros expand to calling routine descriptors. Another reason I did this is because when I tried mixing parts of 68K sprintf/printf/SIOW libraries in the same application with native PPC sprintf/printf/SIOW libraries, I got various crashes. Therefore all I/O is done as 68K in the 68K application, and as native PPC code in the native PPC application. The other choice would have been to decouple the I/O from the NameRegistry code. Because of the nature of how the NameRegistry is used, the code will be doing lots of mixed mode context switches. However in practice, the code doesn't seem too slow. The native PPC glue used in the 68K application is stored in a resource of type 'XCOF', ID = 10000, rather than the data fork. The PCISlots.rsrc file contains default 68K code that puts up an Alert when running the wrong sort of code on a machine; this code can get overridden by the normal build process.
